昨日介紹了可觀測性，今日就要來介紹可觀測性目前流行的解決方案，也就是後半部的主角「Opentelemetry」。

OpenTelemetry（通常稱為 OTel）是一個開源的可觀測性框架，由雲原生基金會(CNCF)托管。是由 OpenCensus 和 OpenTracing 兩個專案合併而成。

OpenTelemetry提供「API 和 SDK」，以及「Collector」，這些元件會用來檢測、產生、收集和匯出遙測資料，遙測資料有以下三種：

• 指標（Metrics）：Metrics提供系統性能和資源使用情況的關鍵數據。OpenTelemetry 支援收集多種Metrics，如記憶體使用率、CPU 使用率等。這些Metrics對於評估系統的整體健康狀況至關重要。
• 日誌（Logs）：log是帶有時間戳記的文字記錄。
• 追蹤（Traces）：Traces可以理解成追蹤、痕跡，其實都行，我英文不怎麼好。但是從字面上我們可以知道，Traces可以追蹤系統的運作，舉例來說到一個請求在應用程式，不同微服務經過了多久，誰先誰後。簡單來說Traces就是Airtag也就是定位器，藉由OpenTelemetry提供不同程式語言的SDK記錄應用程式中的請求流程。
  讓我們可以了解應用程式的整體狀況，透過更細節的資訊，我們可以判斷造成問題的根本原因。

除了上述提到的「API 和 SDK」，以及「Collector」，OpenTelemetry還有一個標準協定「OpenTelemetry Protocol (OTLP)」，裡面會詳述編碼、溝通方式等等，這邊我就不針對協定做詳細介紹。

以上提到的元件可以組成架構如下圖
(圖片取自於Opentelemetry docs)

從圖中我們可以看到，基本的流程大致上是先藉由
OpenTelemetry SDK產生遙測資料 -> OpenTelemetry Collector 收集並且匯出 -> 匯出到可視化工具(例如：Grafana)或者是對應的資料庫中

這邊做個今日小總結

• OpenTelemetry是一個開源的可觀測性框架，由雲原生基金會(CNCF)托管。
• 是由 OpenCensus 和 OpenTracing 兩個專案合併而成。
• 提供「API 和 SDK」，以及「Collector」，這些元件會用來檢測、產生、收集和匯出遙測資料。
• 遙測資料有以下三種：指標（Metrics）、日誌（Logs）、追蹤（Traces）
• OpenTelemetry有一個標準協定OpenTelemetry Protocol (OTLP)
• OpenTelemetry SDK產生遙測資料 -> OpenTelemetry Collector 收集並且匯出 -> 匯出到可視化工具(例如：Grafana)或者是對應的資料庫中

到了最後，那眼尖的小夥伴們可能發現了，怎麼都沒有提到檢測是怎麼個檢測？而圖片中的除了API與SDK還有一個Auto. Inst.，那是什麼？小夥伴們別急，在後續的日子我再跟大家好好介紹。